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(54) Method and system for optimizing performance and availability of a dynamic host 
configuration protocol (DHCP) service 



(57) The present invention discloses a method and 
system for monitoring and optimizing performance and 
availability of a Dynamic Host Configuration Protocol 
(DHCP) service provided by one or a plurality of DHCP 
servers (602) in an Internet Protocol (IP) network com- 
prising one or a plurality of IP subnetworks. 

The method comprises in a DHCP server (602) the 
steps of: 

• defining one or a plurality of groups of subnetworks, 
a group of subnetworks comprising one or a plural- 
ity of subnetworks; 

• retrieving information related to resources, in par- 
ticular IP addresses, allocated within said DHCP 
server to each group of subnetworks; 
transferring said information to a DHCP service 
monitoring system (600). 

The method comprises in a DHCP service monitor- 
ing system (403) the steps of: 

retrieving (501 to 505) from one or a plurality of DH- 
CP servers (401), information related to resources, 
in particular IP addresses, allocated within each 
DHCP server (401 ) to groups of subnetworks, each 
group of subnetworks comprising one or a pluarl'rty 
of subnetworks; 

aggregating (506 to 511) the information for each 
group of subnetworks. 



DHCP Service Monitoring System 
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Description 

Technical field of the invention 

[0001] The present invention relates to computer net- 
works, and more particularly to a method and system in 
an Internet Protocol (IP) network for optimizing perform- 
ance and availability of a Dynamic Host Configuration 
Protocol (DHCP) service provided by a plurality of DH- 
CP servers. 

Background art 

INTERNET 

[0002] Internet is a global network of computers and 
computers networks (the "Net"). The Internet connects 
computers that use a variety of different operating sys- 
tems or languages, including UNIX, DOS, Windows, 
Macintosh, and others. To facilitate and allow the com- 
munication among these various systems and languag- 
es, the Internet uses a language referred to as TCP/IP 
("Transmission Control Protocol/Internet Protocol"). 
TCP/IP protocol supports three basic applications on 
the Internet: 

• transmitting and receiving electronic mail, 

• logging into remote computers (the "Telnet"), and 
transferring files and programs from one computer 
to another ("FTP" or "File Transfer Protocol"). 

[0003] One of the object of TCP/IP is to interconnect 
networks and to provide an universal communication 
services: an inter-network, or Internet. Each physical 
network has its own technology-dependent communica- 
tion interface, in the form of a programming interface 
that provides basic communication functions (primi- 
tives). Communication services are provided by a soft- 
ware that runs between the physical network and user 
applications. This software provides a common inter- 
face for these applications, independent of the underly- 
ing physical network. The architecture of the physical 
networks is hidden from the user. 
[0004] The Internet protocol is still evolving through 
the mechanism of Request For Comments (RFC). New 
protocols (mostly application protocols) are designed 
and implemented by researchers. They are brought to 
the attention of the Internet community in the form of an 
Internet Draft (ID). The largest source of IDs is the In- 
ternet Engineering Task Force (IETF). 

IP ADDRESSES 

[0005] To interconnect two networks, a computer sys- 
tem able to forward packets from one network to the oth- 
er is attached to both networks. Such a machine is called 
a router. The term "IP router" is also used because the 
routing function is part of the IP layer of the TCP/IP pro- 



tocol. 

[0006] IP addresses are used by the IP protocol to 
uniquely identify a host on the Internet (Strictly speak- 
ing, an IP address identifies an interface that is capable 

5 of sending and receiving IP datagrams, and one system 
can have multiple such interfaces. However, both hosts 
and routers must have at least one IP address, so this 
simplified definition is acceptable). IP datagrams (the 
basic data packets exchanged between hosts) are 

10 transmitted by a physical network attached to the host 
and each IP datagram contains a source IP address and 
a destination IP address. 

[0007] IP addresses are represented by a 32-bit un- 
signed binary value which is usually expressed in a dot- 
's ted decimal format. For example, 9.1 67.5.8 is a valid In- 
ternet address. The numeric form is used by the IP soft- 
ware. The mapping between the IP address and an eas- 
ier-to-read symbolic name, for example myhost.ibm. 
com, is done by the Domain Name System 

20 

IP SUBNETS 

[0008] Due to the explosive growth of the I nternet, the 
principle of assigned IP addresses became too inflexible 
25 to allow easy changes to local network configurations. 
Those changes might occur when: 

• A new type of physical network is installed at a lo- 
cation. 

30 • Growth of the number of hosts requires splitting the 
local network into two or more separate networks. 

• Growing distances require splitting a network into 
smaller networks, with gateways between them. 

35 [0009] To avoid having to request additional IP net- 
work addresses in these cases, the concept of subnets 
was introduced. The assignment of subnets can be 
done locally, as the whole network still appears to be 
one IP network to the outside world. 

40 [001 0] The host number part of the IP address is sub- 
divided again into a network number and a host number. 
This second network is termed a subnetwork or subnet. 
The main network now consists of a number of subnets 
and the IP address is interpreted as: 

45 <network numberxsubnet number><host 

number> 

[0011] The combination of the subnet number and the 
host number is often termed the local address or the lo- 
cal part. Subnetting is implemented in a way that is 

50 transparent to remote networks. A host within a network 
that has subnets is aware of the subnetting but a host 
in a different network is not; it still regards the local part 
of the IP address as a host number. 
[001 2] The division of the local part of the IP address 

55 into subnet number and host number parts can be cho- 
sen freely by the local administrator; any bits in the local 
part can be used to form the subnet. The division is done ° 
using a subnet mask which is a 32 bit number. Zero bits 
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in the subnet mask indicate bit positions ascribed to the 
host number, and ones indicate bit positions ascribed to 
the subnet number. The bit positions in the subnet mask 
belonging to the network number are set to ones but are 
not used. Subnet masks are usually written in dotted 5 
decimal form, like IP addresses. 

DOMAIN NAMES 

[001 3] The host or computer names (like www.entre- 10 
prise.com) are translated into numeric Internet address- 
es (like 194.56.78.3), and vice versa, by using a method 
called DNS ("Domain Name Service"). DNS is support- 
ed by network-resident servers, also known as domain 
name servers or DNS servers. 15 

DYNAMIC IP 

[0014] There are generally three pieces of information 
needed by a system in order to be able to communicate 20 
on a TCP/IP network: 

• an IP address (to uniquely identify the system on 
the network), 

• a subnet mask (to determine the network and sub- 25 
net parts of the address), and 

the address of at least one router (if the system is 
to be able to communicate with other devices out- 
side of its immediate subnet). 

30 

[0015] These three values represent the bare mini- 
mum of information that must be programmed into each 
and every device for participating in the TCP/IP world. 
Often the number of necessary parameters will be much 
higher. With the exponential growth rate of networking 35 
today, it is easy to see that manual programming of 
these values into every device that is to attach to the 
network represents a major administrative workload. 
[0016] The increasingly mobile nature of the end us- 
ers also raises problems with regard to configuration of *o 
network devices. It is possible to allocate multiple sets 
of configuration parameters to a device, but: 

• this obviously means even more workload for the 
administrator, <5 

• this is wasteful with respect to the number of IP ad- 
dresses allocated. 
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concentrators and so on. It allows a minimum IP protocol 
stack with no configuration information to obtain enough 
information to begin the process of downloading the 
necessary boot code. BOOTP does not define how the 
downloading is done, but this process typically uses 
TFTP Trivial File Transfer Protocol (TFTP)" as de- 
scribed in RFC 906 - Bootstrap Loading Using TFTP. 
Although still widely for this purpose by diskless hosts, 
BOOTP is also commonly used solely as a mechanism 
to deliver configuration information to a client that has 
not been manually configured. The BOOTP process in- 
volves the following steps: 

1 . The client determines its own hardware address; 
this is normally in a ROM (Read Only Memory) on 
the hardware. 

• 2. A BOOTP client sends its hardware address in a 
UDP (User Datagram Protocol) datagram to the 
server. If the client knows its IP address and/or the 
address of the server, it should use them, but in gen- 
eral BOOTP clients have no IP configuration data 
at all. If the client does not know its own IP address, 
it uses 0.0.0.0. If the client does not know the serv- 
ers IP address, it uses the limited broadcast ad- 
dress (255.255.255.255). The UDP port number is 
67. 

• 3. The server receives the datagram and looks up 
the hardware address of the client in its configura- 
tion file, which contains the client's IP address. The 
server fills in the remaining fields in the UDP data- 
gram and returns it to the client using UDP port 68. 

• 4. When it receives the reply, the BOOTP client will 
record its own IP address and begin the bootstrap 
process. 

[0019] BOOTP is a draft standard protocol. Its status 
is recommended. The BOOTP specifications can be 
found in RFC 951 - Bootstrap Protocol. There are also 
updates to BOOTP, some relating to inter operability 
with DHCP (Dynamic Host Configuration Protocol), de- 
scribed in RFC 1542 - Clarifications and Extensions for 
the Bootstrap Protocol, which updates RFC 951 and 
RFC 2132 - DHCP Options and BOOTP Vendor Exten- 
sions. 



[0017] Several components of TCP/IP help automate 
device configuration, reduce the number of IP address- 
es allocated, and/or cope with the demands of the mo- 
bile user. 

BOOTSTRAP PROTOCOL (BOOTP) 

[001 8] The BOOTP protocol was originally developed 
as a mechanism to enable diskless hosts to be remotely 
booted over a network as workstations, routers, terminal 



DYNAMIC HOST CONFIGURATION PROTOCOL 
(DHCP) 

[0020] The Dynamic Host Configuration Protocol 
(DHCP) provides a framework for passing configuration 
information to hosts on a TCP/IP network. DHCP is 
based on the BOOTP protocol, adding the capability of 
automatic allocation of reusable network addresses and 
additional configuration options. DHCP messages use 
UDP port 67, the BOOTP server's well-known port and 
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UDP port 68, the BOOTP client's well-known port. DH- 
CP consists of two components: 

1. A protocol that delivers host-specific configura- 
tion parameters from a DHCP Server to a host. 

• 2. A mechanism for the allocation of temporary or 
permanent network addresses to hosts. 

[0021] IP requires the setting of many parameters 
within the protocol implementation software. Because 
IP can be used on many dissimilar kinds of network 
hardware, values for those parameters cannot be 
guessed at or assumed to have correct default values. 
The use of a distributed address allocation scheme 
based on a polling / defence mechanism, for discovery 
of network addresses already in use, cannot guarantee 
unique network addresses because hosts may not al- 
ways be able to defend their network addresses. DHCP 
supports three mechanisms for IP address allocation: 

• 1. Automatic allocation : DHCP assigns a perma- 
nent IP address to the host. 

• 2. Dynamic allocation : DHCP assigns an IP ad- 
dress for a limited period of time. 

• 3. Manual allocation : The host's address is as- 
signed by a network administrator. 

[0022] DHCP is a draft standard protocol. Its status is 
elective. The current DHCP specifications can be found 
in RFC 2131 - Dynamic Host Configuration Protocol and 
RFC 2132 - DHCP Options and BOOTP Vendor Exten- 
sions. 

Configuration Parameters Repository 

[0023] DHCP provides persistent storage of network 
parameters for network clients. A DHCP Server stores 
a key-value entry for each client, the key being some 
unique identifier, for example an IP subnet number and 
a unique identifier within the subnet (normally a hard- 
ware address), and the value contains the configuration 
parameters last allocated to this particular client. 
[0024] One effect of this is that a DHCP client will tend 
to always be allocated the same IP address by the serv- 
er, provided the pool of addresses is not over-sub- 
scribed and the previous address has not already been 
allocated to another client. 

DHCP Considerations 

[0025] DHCP dynamic allocation of IP addresses and 
configuration parameters relieves the network adminis- 
trator of great deal of manual configuration work. The 
ability for a device to be moved from network to network 
and to automatically obtain valid configuration parame- 
ters for the current network can be of great benefit to 
mobile users. Also, because IP addresses are only al- 
located when clients are actually active, it is possible, 



by the use of reasonably short lease times and the fact 
that mobile clients do not need to be allocated more than 
one address, to reduce the total number of addresses 
in use in an organization. However, the following should 
5 be considered when DHCP is being implemented: 

DHCP is built on UDP, which is, as yet, inherently 
insecure. In normal operation, an unauthorized cli- 
ent could connect to a network and obtain a valid 
10 IP address and configuration. To prevent this, it is 
possible to preallocate IP addresses to particular 
MAC (Medium Access Control) addresses (similar 
to BOOTP), but this increases the administration 
workload and removes the benefit of recycling of 
addresses. 
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Unauthorized DHCP Servers could also be set up, 
sending false and potentially disruptive information 
to clients. 

In a DHCP environment where automatic or dynam- 
ic address allocation is used, it is generally not pos- 
sible to predetermine the IP address of a client at 
any particular point in time. In this case, if static DNS 
( Domain Name Server) servers are also used, the 
DNS servers will not likely contain valid host name 
to IP address mappings for the clients. If having cli- 
ent entries in the DNS is important for the network, 
one may use DHCP to manually assign IP address- 
es to those clients and then administer the client 
mappings in the DNS accordingly. 

BOOTP and DHCP Inter operability 



35 [0026] The format of DHCP messages is based on the 
format of BOOTP messages, which enables BOOTP 
and DHCP clients to interoperate in certain circumstanc- 
es. Support for BOOTP clients at a DHCP Server must 
be configured by a system administrator, if required. 

40 

DYNAMIC DOMAIN NAME SYSTEM 

[0027] In order to take advantage of DHCP, yet still to 
be able to locate any specific host by means of a mean- 
45 ingful label, such as its host name, the following exten- 
sions to the Domain Name System (DNS) are required: 

A method for the host name to address mapping 
entry for a client in the domain name server to be 
50 updated, once the client has obtained an address 
from a DHCP Server. 

A method for the reverse address to host name 
mapping to take place once the client obtains its ad- 
55 dress. 

• Updates to the DNS to take effect immediately, with- 
out the need for intervention by an administrator. 
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Updates to the DNS to be authenticated to prevent 
unauthorized hosts from accessing the network and 
to stop imposters from using an existing host name 
and remapping the address entry for the unsuspect- 
ing host to that of its own. 

• A method for primary and secondary DNS servers 
to quickly forward and receive changes as entries 
are being updated dynamically by clients In short, 
a secure Dynamic Domain Name System (DDNS) 
is necessary. 

[0028] In summary, in the DHCP and DDNS environ- 
ment, DHCP provides a device with a valid IP address 
for the point at which it is attached to the network. DDNS 
provides a method of locating that device by its host 
name, no matter where that device happens to be at- 
tached to a network and what IP address it has been 
allocated. 

[0029] More explanations about the domain present- 
ed in the above sections can be found in the following 
publications incorporated herewith by reference: 

• TCP/IP Tutorial and Technical Overview by Martin 
W. Murhammer, Orcun Atakan, Stefan Bretz, Larry 
R. Pugh, Kazunari Suzuki, David H. Wood pushibed 
by IBM International Technical Support Organiza- 
tion. 

"Internet in a nutshell" by Valerie Quercia, published 
by O'Reilly, October 1997. 

PROBLEM 

[0030] The problem is to monitor the utilization of a 
Dynamic Host Configuration Protocol (DHCP) service 
provided by one or a plurality of DHCP servers, in order 
to optimally adjust configuration parameters. Due to the 
nature of DHCP protocol which is based on UDP 
BOOTP broadcast, the DHCP service is provided to the 
DHCP Client by the "fastest" DHCP Server to answer. 
As a consequence, in a multiple DHCP Servers environ- 
ment, when a DHCP Server fails or when a DHCP Serv- 
er reachs its maximum capacity, the DHCP Servers 
which are still available continue to provide a DHCP 
Service and to answer DHCP Client requests. The avail- 
able DHCP Servers continue to provide the service until 
they reach their maximum capacity. Eventually the DH- 
CP Service may fail because available DHCP Servers 
cannot support the total load. 

[0031] A single DHCP Server may be configured to 
provide a DHCP Service to multiple subnetworks or 
groups of subnetworks. In this case, the DHCP Server 
is configured with one pool of IP addresses per subnet- 
work. The capacity or size of a pool is defined by the 
number of IP adresses this pool can manage. 
[0032] In addition, for better resilience and better per- 
formance, a group of subnetworks can be administered 
by multiple DHCP Servers. In this case, the DHCP Serv- 



ice is provided by this plurality of DHCP Servers. 
[0033] Note : in the present invention, "a group of sub- 
networks" comprises one or multiple subnetworks also 
called "IP subnets" generally located in a same geo- 
5 graphical area. 

[0034] The problems are then to: 

• monitor the utilization of the DHCP Service for each 
group of subnetworks. 
10 • monitor the pools of IP addresses configured within 
each DHCP Server. 

correlate and monitor for each group of subnet- 
works, the utilization of the pools of IP addresses 
configured on multiple DHCP Servers 
15 • detect any capacity problem on DHCP Servers, in 
order to anticipate any DHCP Service degradation 
or disruption. 

[0035] The DHCP Service provided when one DHCP 
20 Server has reached its maximum capacity is degraded 
because the DHCP Servers which are still available 
have to handle additional load. The monitoring of a DH- 
CP Service without analysis of its utilisation cannot not 
lead to an efficient anticipation of the problems, in par- 
25 ticular disruption or degradation of the DHCP Service. 

Objects of the invention 



• One object of the present invention is to provide a 
method for optimizing performance and availability 
of a DHCP Service. 

35 • it is a further object of the present invention to mon- 
itor the utilisation of a DHCP Service for each group 
of subnetworks. 

It is another object of the present invention to mon- 
40 itor the pools of IP addresses configured within 
each DHCP Server. 

It is yet another object of the present invention to 
correlate and monitor the utilization of the pools of 
<5 |p addresses configured on multiple DHCP Servers 
for each group of subnetworks. 

It is yet another object of the present invention to 
detect any capacity problem on DHCP Servers. 

50 

• It is another object of the present invention to check 
that every DHCP Server is correctly configured. 



[0037] The present invention discloses a method and 
system for monitoring and optimizing performance and 
availability of a Dynamic Host Configuration Protocol 



50 

• It is another object of the 
that every DHCP Server 

Summary of the invention 

55 
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(DHCP) service provided by one or a plurality of DHCP 
servers in an Internet Protocol (IP) netwZ,Z 
one or a plurality of IP subnTSs 
[0038] More particularly the present invention uses 
specific probes for collecting information related to th! S 
uh-ization of IP address pools within said DHCP Se^! 

[0039] The present invention also uses a DHrp 

» Utilisation application for conJ^^E^ 

m£l 9 reports and statistics. 

steps of: m6th0d C ° mpriSeS in a DHCP se ^r the 

' !icl e Mp 9 i n d f r at, '° n re,3,ed t0 reS0Urces - in Par- 
ticular IP addresses, allocated within said DHCP 

server to each group of subnetworks- 
• transferring said information to a DHCP service 
monitoring system. ™ ICe 

[0041] The method comprises in a DHCP service 
monrtonng system the steps of: 

retrieving from one or a plurality of DHCP servers 
-nformafon related to resources, in particular^ 
dresses, allocated within each DHCP server to 
groups of subnetworks, each group of subnet 5 
">mpns,ng one or a plurality of subnetworks 
• ^ingthein^nforeachg^ofsub- 



thereof, will best be understood by reference to th» mi 

bodiment when read in conjunction with the accomoT 
nymg drawings, wherein : accompa- 

• Figure 1 shows the IP address allocation to a DHCP 
Cent by a DHCP Server according to pt art 

• ^ ur o2i S av,ewofaDHCPserverprobeaccording 
to the present invention. 9 

Figure 5 is a flow chart of a DHCP group probe ac- 
cording to the present invention. pproDeac 

6 '? PhySiCa ' Vi6W0f a °HCP service mon- 
'tormg system according to the present invention 
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Preferred embodiment of the invention 



o^HCp h L P ^ e^, in : 6nti0n re,ateS t0 ,he m «9 
or a DHCP service and more particularly to a method 

and system for checking the si* of .P address poS£ 

- DHCPse^ S t e,WOrkS am ° n9 ° ne or a 

DHCP servers. The present invention is based on th* 

= re of utifcation of IP address poo!st me- of 



Stages"" PreS6nt inVenti ° nS Pr0VWeS ,he fo,, ° wi "9 

• Early detection of IP address shortage in pools con 

• Early detection of any capacity problem on DHCP 

anStf ^ 9r ° UP ° f SUbnetWorks in order to 

• an * se,vice degradation or disruption 
Production of DHCP Service utilisation reports for 
adjusting configuration of DHCP Servers (Cam 
Pte, increase of the s*eof an IP address pool for a 
specie grou p of subnets on a DHCP Se^ er ) 
No add,t,onal or specific hardware is mandatory 
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IP ADDRESS ALLOCATION 



Drawings 

KLibosTrn ^ inVe " t,Ve fea,Ures bel ^ed 
th ' nVenti0n are set forth * the ap- 
Pended cla.ms. The invention itself, however, as well as 

apreferredmodeofuse,furtherobject S andadvama g es 



[0045] Figure 1 describes the DHCP Client/Server in 
work address. More particularly, Figure 1 shows the ar 

CPs! ^ P T ma,Mnfi »Parametersfro^DH 
broadcasts a request on its local physical subnet (103) 
flrwl^^^ 

Aether TLrf r ^ ° HCP Server 
the DHCP If , anSW6r the DHCP C,ient or "of. If 
w^hinT 1 haS St '" some availab,e IP address 
wrthin its address database, a positive answer is re! 

Sved Z T ° r WhlCh 3 positive ans «ar is re- 

S m ^ ,0 ,hiS SefVer te a ^ement. 

S LoT* Pa,1iCU ' ar,y the a " ocation ° f 3 new net- 
work address comprises the following steps: 

The DHCP Client broadcasts a request on its local 
tons such as network address suggestion or lease 
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• Each DHCP Server may respond with a message 
that includes an available network address and oth- 
er configuration options. The DHCP Server may 
record the address as offered to the DHCP Client 

to prevent the same address being offered to other 5 
DHCP Clients in the event of further messages be- 
ing received before the first DHCP Client has com- 
pleted its configuration. 

• The DHCP Client receives one or more messages 10 
from one or more DHCP Servers. The DHCP Client 
chooses one based on the configuration parame- 
ters offered and broadcasts a message that in- 
cludes the DHCP Server identifier option to indicate 
which message it has selected and the requested is 
IP address option, taken from the DHCP Client IP 
address in the selected offer. 

The DHCP Servers receive the messages broad- 
casted by the DHCP Client. Those DHCP Servers 20 
not selected use the message as notification that 
the DHCP Client has declined that DHCP Server's 
offer. The DHCP Server selected in the message 
commits the binding for the DHCP Client to persist- 
ent storage and responds with a message contain- 25 
ing the configuration parameters for the requesting 
DHCP Client. 

The DHCP Client receives the message with con- 
figuration parameters and performs a final check on 30 
the parameters. At this point the DHCP Client is 
configured. 

INTERNAL VIEW OF A DHCP SERVER PROBE 

35 

[0047] Figure 2 is a logical view of a DHCP Server 
Probe (202). The DHCP Server Probe runs concurrently 
with the DHCP Server application (201). The DHCP 
Server Probe (202) within the DHCP Server (200) de- 
termines, the current number of allocated IP addresses <o 
for each group of subnetworks and saves this informa- 
tion in a file (203) called "Server Utilisation File" (in a 
preferred embodiment, there is one entry in the Server 
Utilisation File for each group of subnetworks). A group 
of subnetworks is in fact a list of IP subnetworks (or IP *5 
subnets) stored in a file (204) generally called "Group 
File" (in a preferred embodiment, the file name is the 
group name for a better identification of the information). 
A workstation broadcasting an IP address allocation re- 
quest from its local subnetwork, will be served by a 50 
unique DHCP Server. The Group File (204) in a DHCP 
Server comprises in fact the list of IP subnetworks be- 
longing to a same group. 

DYNAMIC VIEW OF A DHCP SERVER PROBE 55 

[0048] Figure 3 is a flow chart of a DHCP Server 
Probe as described in Figure 2. The DHCP Server 
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Probe is executed at given and regular period of times. 
Information collected by the probe is recorded in a file 
(Server Utilisation File - 203) containing for each group 
of subnetworks, the total number of IP addresses within 
the pool and the number of IP addresses used or allo- 
cated. The process comprises the following steps: 

• (301 ) The Server Utilization File in the DHCP Server 
is opened. 

(302) A test determines whether there is a Group 
File to process or not. 

• (3 1 3) If there is no more Group File to process, 
the Server Utilization File in the DHCP Server 
is closed. 

• If there is still a Group File to process: 

(303) The group name is extracted from the 
Group File (in a preferred embodiment the 
group name is extrapolated from the Group 
File name). 

(304) The list of subnetworks that belongs 
to the group is extracted from the Group 
File. 

(305) A first counter called "Total Group 
Pool Size counter" is initialized for the 
group. This counter is used to determine 
the total number of IP addresses that can 
be allocated to this group (available and al- 
located IP addresses). 

(306) A second counter called "Total Group 
Pool Used counter" is initialized for the 
group. This counter is used to determine 
the total number of IP addresses actually 
allocated to this group. 

(307) A test determines whether there is a 
subnetwork within the group to process or 
not. 

If there is a subnetwork to process: 

(308) The size of the pool associ- 
ated with the subnetwork is re- 
trieved from the DHCP Server Ap- 
plication. 

• (309) The size of the pool is added 
to the Total Group Pool Size 
stored in the Total Group Pool Size 
counter. 

(310) The number of allocated IP 
addresses associated with the 
subnetwork is retrieved from the 
DHCP Server Application. 

(311) The number of allocated IP 
addresses is added to the Total 
Group Pool Used stored in the To- 
tal Group Pool Used counter. 
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When ail subnetworks have been 
processed: 

• (312) The Server Utilisation File is 
updated with the following infor- 
mation: 

name of the group; 

• Total Group Pool Used; 

• Total Group Pool Size; 
a time stamp. 
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DHCP GROUP PROBE 



[0049] Figure 4 is a view of a DHCP Group Probe 
(405). The probe can be processed either in a DHCP 
Monitoring System (403) or in any DHCP Server. The 
purpose of a DHCP Group Probe is to compute for each 
group of subnetworks administered by one or a plurality 
of DHCP Servers, the global utilisation of the IP address 
pools. The DHCP Group Probe collects the information 
previously processed by DHCP Server Probes on DH- 
CP Servers (401). 

• The information is stored in the Server Utilization 
File (402) of each DHCP Server (401) administering 
the group. 

DHCP Servers are recorded in a list called "DHCP 
Servers List File" (404). The collected information 
is then aggregated in several files (one per group) 
called "Group Utilisation Files" (406). Each file con- 
tains all information related to the utilization of IP 
address pools for a given group, in particular the 
percentage of utilisation of IP addresses. To avoid 
any IP address shortage in IP address pools, spe- 
cific actions (for instance, increase of a pool size in 
a DHCP Server) can then be launched if, for in- 
stance, the computed percentage exceeds a pre- 
defined threshold. 

DYNAMIC VIEW OF A DHCP GROUP PROBE 

[0050] Figure 5 is a flow chart of a DHCP Group 
Probe. The probe is preferably executed at given and 
regular periods of time. The information for each group 
of subnetworks is collected in the different DHCP Serv- 
ers. A file (404) in the DHCP Monitoring System (403) 
contains an exhaustive list of the DHCP Servers admin- 
istering each group of subnetworks. The following proc- 
ess in the DHCP Monitoring System (403) is then exe- 
cuted: 



15 



20 



25 



30 



35 



40 



45 



50 



(501) A DHCP Server (in a preferred embodiment, 
the DHCP Server name, or address) is retrieved 
from the DHCP Servers List File (404). 55 

(502) A test determines whether there is still a DH- 
CP Server to process or not. 



• If there is a DHCP Server to process: 

• (503) A connection is established with the 
DHCP Server (401). 

• (504) The Server Utilisation File (402) is re- 
trieved from the DHCP Server. 

• (505) The connection with the DHCP Serv- 
er is terminated. 

• When there is no more DHCP Server to proc- 



• (506) An exhaustive list of the groups is ex- 
trapolated from the Server Utilisation Files 
previously retrieved from DHCP Servers 
(note each Server Utilisation File contains 
group names, and a same group name 
may be present in multiple Server Utilisa- 
tion Files). 

• (507) A test determines whether there is 
still a group to process or not: 

• If there is still a group to process: 

• (508) Data for the group (Total 
Group Pool Used, Total Group 
Pool Size) are retrieved from 
Server Utilisation Files. 

• (509) The global utilization of the 
IP address pools for the group is 
computed. In a preferred embodi- 
ment, the global utilisation is equal 
to sum of Total Group Pool Used 
variables, divided by sum of all To- 
tal Group Pool Size variables. 
An action (for instance an alert) 
can be sent if a predefined thresh- 
old has been reached for this 
group. 

• (510) The global utilisation of the 
IP address pools for the group is 
recorded with a time stamp. 

• (511) When there is no more 
group to process, a successful re- 
turn code is returned. 

DHCP SERVICE MONITORING SYSTEM 

[0051] Figure 6 is a view of a DHCP Service Monitor- 
ing system (600) within an IP network. A dedicated com- 
puter system can be used to run the DHCP Group 
Probes (601) and to collect the information located in 
each DHCP server (602) by DHCP Server Probes (603). 
[0052] While the invention has been particularly 
shown and described with reference to a preferred em- 
bodiment, it will be understood that various changes in 
form and detail may be made therein without departing 
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from the spirit, and scope of the invention. of the preceding claims. 



Claims 

1. A method for monitoring and optimizing perform- 
ance and availability of a Dynamic Host Configura- 
tion Protocol (DHCP) service provided by one or a 
plurality of DHCP servers (602) in an Internet Pro- 
tocol (IP) network comprising one or a plurality of 
IP subnetworks, said method comprising in a DHCP 
server (602) the steps of: 

defining one or a plurality of groups of subnet- 
works, each group of subnetworks comprising 
one or a plurality of subnetworks; 

• retrieving information related to resources, in 
particular IP addresses, allocated within said 
DHCP server to each group of subnetworks; 

• transferring said information to a DHCP service 
monitoring system (600). 

2. The method according to the preceding claim 
wherein the step of retrieving information related to 
resources allocated to each group of subnetworks 
comprises the further step of: 

determining a total number of IP addresses 
presently allocated to each group of subnet- 
works, the total number of IP addresses of a 
group of subnetworks being equal to the sum 
of IP addresses presently allocated to each 
subnetwork defined within said group of sub- 
networks. 

3. The method according to any one of the preceding 
claims wherein the step of retrieving information re- 
lated to resources allocated to each group of sub- 
networks comprises the further step of: 

• determining a total number of IP addresses that 
can be potentially allocated to each group of 
subnetworks, the total number of IP addresses 
of a group of subnetworks being equal to the 
sum of IP addresses that can be potentially al- 
located to each subnetwork defined within said 
group of subnetworks. 

4. The method according to any one of the preceding 
claims comprising the further step of: 

• storing the total number of IP addresses pres- 
ently allocated to each group and/or that can 
be potentially allocated to each group of sub- 
networks in a file (203) within the DHCP server. 

5. A system, in particular a DHCP server (200), adapt- 
ed for carrying out the method according to any one 



6. A computer readable medium comprising instruc- 
tions adapted for carrying out the method according 

5 to any one of steps 1 to 4. 

7. A method for monitoring and optimizing perform- 
ance and availability of a Dynamic Host Configura- 
tion Protocol (DHCP) service provided by one or a 

10 plurality of DHCP servers (401 ) according to claim 
5 in an Internet Protocol (IP) network comprising 
one or a plurality of IP subnetworks, said method 
comprising in a DHCP service monitoring system 
(403) the steps of: 

15 

retrieving (501 to 505) from one or a plurality of 
DHCP servers (401), information related to re- 
sources, in particular IP addresses, allocated 
within each DHCP server (401) to groups of 
20 subnetworks, each group of subnetworks com- 

prising one or a plurality of subnetworks; 
• aggregating (506 to 511) said information for 
each group of subnetworks. 

25 8. The method according to the preceding claim 
wherein the retrieved information comprises for 
each DHCP server a total number of IP addresses 
presently allocated to each group of subnetworks, 
the total number of IP addresses of a group of sub- 
so networks in a DHCP server being equal to the sum 
of IP addresses presently allocated to each subnet- 
work defined within said group of subnetworks. 

9. The method according to any one of claims 7 to 8 
35 wherein the retrieved information comprises for 

each DHCP server a total number of IP addresses 
that can be potentially allocated to each group of 
subnetworks, the total number of IP addresses of a 
group of subnetworks in a DHCP server being equal 
40 to the sum of IP addresses that can be potentially 
allocated to each subnetwork defined within said 
group of subnetworks. 

10. The method according to any one of claims 7 to 9 
45 comprising a first step of: 

recording said one or plurality of DHCP servers 
in a list (404); 

50 11. The method according to any one of claims 7 to 10 
wherein the step of aggregating (506 to 511) said 
information for each group of subnetworks compris- 
es the further step of: 

55 • building (506) a list of groups of subnetworks 
using information retrieved from DHCP serv- 
ers. 



35 



40 



9 



17! 



EP 1 079 583 A1 



12. The method according to any one of claims 7 to 11 
wherein the step of aggregating (506 to 511) said 
information for a group of subnetworks comprises 
the further step of: 

• determining a total number of IP addresses 
presently allocated to said group of subnet- 
works on all DHCP servers, the total number of 
IP addresses being equal to the sum of IP ad- 
dresses presently allocated to said group of 
subnetworks in each DHCP server. 



18. A computer readable medium comprising instruc- 
tions adapted for carrying out the method according 
to any one of steps 7 to 16. 
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13. The method according to any one of claims 7 to 12 
wherein the step of aggregating (506 to 511) said 
information for a group of subnetworks comprises 15 
the further step of: 

determining a total number of I P addresses that 
can be potentially allocated to said group of 
subnetworks on all DHCP servers, the total 20 
number of IP addresses being equal to the sum 
of IP addresses that can be potentially allocat- 
ed to said group of subnetworks in each DHCP 
server. 

25 

14. The method according to any one of claims 7 to 1 3 
wherein the step of aggregating (506 to 511) said 
information for a group of subnetworks comprises 
the further step of: 

30 

dividing the total number of IP addresses pres- 
ently allocated to said group of subnetworks on 
all DHCP servers by the total number of IP ad- 
dresses that can be potentially allocated to said 
group of subnetworks on all DHCP servers; 35 
comparing the result of the division with a pre- 
determined threshold; 

• triggering a corrective action when this thresh- 
old is reached for a group of subnetworks. 

40 

15. The method according to any one of claims 7 to 14 
wherein the step of triggering a corrective action 
comprises the further step of: 

• triggering an alert; or/and 45 

• adjusting within one or a plurality of DHCP serv- 
ers the number of IP addresses that can poten- 
tially be allocated to said group. 



1 6. The method according to any one of claims 7 to 1 5 so 
wherein the step of retrieving information is execut- 
ed at predefined or/and regular periods of time on 
request of the DHCP service monitoring system 
(403). 

55 

17. A system, in particular a DHCP service monitoring 
system (403) adapted for carrying out the method 
according to any one of claims 7 to 16. 



10 




EP 1 079 583 A1 



IP Address Allocation 



DHCP 
Server 
(102) 



DHCP 
Server 
(102) 



IP Network 



DHCP 
Client 
(101) 



DHCP 
Client 
(101) 



DHCP 
Client 
(101) 



FIG.1 



11 



EP 1 079 583 A1 



# 



DHCP Server Application 



DHCP Server Application 
(201) 




Group file 1 
(204) 




/Giroup file 2 
VJ205) 



DHCP Server Probe 



(202) 




Server Utilizations 
(203) 




DHCP Server (200) 



FIG. 2 



12 



EP 1 079 583 A1 



DHCP Server Probe 



open Server Utilization File 



J30H 



No 



Close Server 
Utilization File 



(313) 



Write Group utilization data 
into Server Utilization File: 
. Group name 
. Total Group Pool used 
. Total Group Pool Size 
. Timestamp 



'A Group Fil^ 
to process ? 
J302) 

fYes 



Extract Group name from Group File 

(303) 






Extract Subnet list from Group File 

1304) 


1 




Reset Total Group Pool Size 

(305) 






Reset Total Group Pool Used 

(306) 








Get Pool Size from DHCP Server 
application for this subnet qqs) 



Add Pool Size to Total Group 
Pool Size (3Q9) 



get number of used IP address, from DHCP 
Server application, for this Subnet (31 0) 

1 



Add number of used IP addresses to 
Total Group Pool 



FIG. 3 



(311) 



13 



EP 1 079 583 A1 



DHCP Group Probe 




FIG. 4 



14 



EP 1 079 583 A1 



DHCP Group Probe 



Build an exhaustive list 
of Groups, using the 
Server Utilization Files 
(506) 




Extract utilization 
data for the Group, 
from all Server Utilization 
File s (508) 



Compute the global 

utilization data 
(509) 



Get DHCP Server from DHCP 

Servers List File (501) 




Get Server Utilization File 1 
from DHCP Server (504)1 



Disconnect to DHCP Server 

(505)1 



Timestamp and record 

the global utilization 
data (510) 



Return code OK 
(511) 



FIG. 5 



15 



EP 1 079 583 A1 



DHCP Service Monitoring System 



DHCP 
Server 
(602) 



602) / 



Server 
Probe 
(603) 



DHCP Carw/ar 

c^.^r Server 

Server d ,«k« 

/ fin o\ .Probe 




DHCP 
Client 



DHCP 
Client 



DHCP 
Client 



FIG. 6 



16 



EP 1 079 583 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



AppOcstton 

EP 99 48 0077 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



CHaUon of documerri wffh Indication, whore appropriate, 
of relevant passage 



Relevant 
to ctalm 



CLASSIFICATION OF THE 
APPLICATION (*rttCt7) 



A 
A 



"IP AddressWorks" 
ONSIGTH SOLUTIONS, 'Online! 1998, 
XP002129978 

Retrieved from the Internet: 

<URL : http ://www. i pworks . nl/i paw-spd . htm> 

'retrieved on 2000-02-07! 

* the whole document * 

W0 99 33211 A (U S WEST INC ;NEDIA0NE 
GROUP INC (US)) 1 July 1999 (1999-07-01) 

* page 5, line 10 - page 14, line 15 * 

DR0MS R: "Automated configuration of 
TCP/IP with DHCP" 

IEEE INTERNET COMPUTING, JULY-AUG. 1999, 
IEEE, USA, 

vol. 3, no. 4, pages 45-53, XP000874503 
ISSN: 1089-7801 

* the whole document * 



1-13,17 
18 



14-16 
1-18 



H04L29/06 
H04L12/24 



(tatcj.7) 



H04L 



The present search report has been drawn up tor all claims 



THE HAGUE 



Dale c* completion ol the March 

8 February 2000 



RAMIREZ DE AREL.., F 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant tf taken alone 

Y : particularly relevant H combined nfth another 

document of the same category 
A : technological background 
O : non-wrttten disclosure 
P : tntermedtale document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on. or 

after the fling date 
D : document died in the application 
L : documerri ched for other reasons 

& : member of the same patent family, corresporrfing" 
document 



17 



EP 1 079 583 A1 



3SKS2S "SSSK" 



EP 99 48 0077 



the above-mentioned European 



search report. 



08-02-2000 




the European Palent Office, 



No. 12/82 



18 



